前言

許多開發者初次接觸 AI Agent，會被 ReAct (Reasoning and Acting) 框架的簡潔與強大所吸引，並迅速用幾十行程式碼實現一個能與工具互動的簡單 Agent，甚至不需要使用到任何套件。

這很棒，卻也容易造成一種錯覺：既然能動，就離上線不遠了。真正在複雜客戶端場景（斷線重連、頁面重整、多工具協作、人工審批、長任務）提供穩定、可維運的體驗，往往要靠完整的 Agent Framework 來補齊工程面的縫隙。ReAct 是提示與互動的模式，而一個好的 Framework 才是把它變成產品的關鍵。

冰山一角的 ReAct 迴圈與 LLM Agent 的差距

短短幾行程式碼，就能實現一個「Thought -> Action -> Observation」的閉環，讓模型看起來像是在推理、決策，甚至一步步探索問題解法。這種直觀的迴圈往往能在黑板上、在簡報中、甚至在 hackathon 裡迅速展現效果，給人一種「智慧真的在這裡誕生」的感覺。

它的魅力來自於：

• 概念簡單：Thought -> Action -> Observation，流程清楚、直觀易懂。
• 快速驗證：非常適合做 PoC（Proof of Concept），能在短時間內證明一個想法是否可行，往往幾十分鐘就能跑出一個 demo。

然而，這種看似堅固的迴圈，其實更像漂浮在水面上的冰山頂端。當場景變得複雜，隱藏在水面下的結構性脆弱就會暴露出來：

它的脆弱之處在於：

• 無記憶：每次執行都是全新的開始，無法累積過去的經驗與互動。
• 無狀態：一旦遇到中斷（例如網路錯誤或使用者關閉頁面），整個進度就會完全遺失。
• 流程僵化：在單純的線性迴圈中，很難自然地加入分支判斷、例外處理，或是人類審批等真實場景必須的複雜邏輯。
• 難以維護：所有邏輯——Prompt、工具呼叫、歷史紀錄管理——往往混雜在同一層程式碼裡，牽一髮而動全身，讓系統隨著功能增加變得愈來愈脆弱。

支撐 LLM Agent 的核心支柱

一個能跑起來的 ReAct 迴圈，就像搭好的雛形引擎；它能啟動，但遠遠不足以驅動真實世界的任務。要讓 Agent 走進產品環境並承受長時間運行、斷線重連、多角色協作等挑戰，必須有幾根「支柱」撐住它。

這些支柱分別解決三個現實問題：如何保持對話與任務的連貫性（記憶體管理）、如何確保遇到中斷仍能繼續（持久性與狀態管理）、以及如何處理非線性的決策與人機協作（工作流設計）。沒有這些支柱，Agent 就只能停留在玩具階段；有了它們，才有機會演變成能真正落地的應用。

記憶管理：從失憶到擁有智慧

🚫 沒有記憶的 LLM
使用者：嗨，我叫 Mike Hsu。
LLM：嗨，很高興認識你！
使用者：我剛才說我叫什麼名字？
LLM：抱歉，我不確定，你還沒告訴過我。
-----
✅ 有記憶的 LLM（具備短期對話記憶）
使用者：嗨，我叫 Mike Hsu。
LLM：嗨，Mike Hsu，很高興認識你！
使用者：我剛才說我叫什麼名字？
LLM：你剛才說你叫 Mike Hsu。

沒有記憶的 Agent，就像金魚般每 7 秒認識一次你；它也許能完成一兩步互動，但很快就會在冗長任務與跨會話需求前現出原形。真正的「智慧」，來自於能把當下的上下文抓牢（短期記憶），並把跨時間的偏好與知識沉澱下來（長期記憶）。兩者相互配合：前者保證對話不斷線，後者讓互動越用越懂你。

短期記憶（Short-term Memory）

短期記憶主要承擔「當前脈絡」的維護。例如在一段對話或任務流程中，Agent 需要記住使用者剛剛的訊息、工具呼叫的結果、暫存的變數。這讓互動變得自然連貫，而不是每次都要從頭解釋。短期記憶通常以對話歷史、上下文緩衝或臨時狀態儲存來實現。

• 目的：維持對話和任務的上下文，不必在每一輪都重複所有資訊。
• 常見做法：保留同一個 session 內的訊息歷史，或透過「視窗化」與「摘要化」策略，只抓取近期相關的內容，避免模型負擔過重。
• 價值：自動化地管理上下文長度，避免提示（prompt）溢位；同時利用壓縮或摘要機制，把不重要的細節排除掉，只留下能支持推理與決策的關鍵訊息。

在 Agent 具備短期記憶後，一個常見挑戰是長對話很快就會超出語言模型的上下文視窗。為了避免這種情況，系統通常需要有一套「記憶管理」機制。最基本的做法是修剪訊息，也就是在送入模型前刪除過舊或不重要的對話內容。

進一步的方式是透過摘要，將早期的歷史濃縮成簡短的敘述，保留核心語意而非逐字回放。除此之外，也能利用檢查點的方式，把對話歷史儲存下來，必要時再擷取，甚至可以設計更進階的自訂策略，例如依訊息的角色、主題或重要性來篩選。這些方法讓代理能在對話過程中持續「記得你剛剛說過什麼」，同時又不會因為訊息過多而壓垮模型的上下文限制。

長期記憶（Long-term Memory）

如果短期記憶讓代理能在單一對話中保持流暢，那麼長期記憶就是讓代理「跨越時間」的基礎。它的目的在於實現個人化與知識沉澱，讓系統不僅能記得你在這一輪說了什麼，也能在不同的 session 中延續對你的理解，逐步形成「這就是你」的形象。

長期記憶的挑戰在於，它不像短期記憶有一個簡單的上下文視窗上限，而是涉及「該記住什麼」、「怎麼更新」、「何時取用」等更複雜的問題。人類的記憶可分為語義（事實）、情景（經驗）、程序（規則），同樣的分類也能套用在 AI 代理身上：它可以記住使用者的偏好與基本資料（事實記憶）、過往互動的脈絡（情景記憶），甚至在任務執行中累積規則或模式（程序記憶）。

在技術上，常見的做法包括：

• 語意記憶：使用向量資料庫來儲存對話片段或文件，讓代理能夠透過相似度檢索「回想起」相關經驗。
• 事實記憶：透過鍵值存儲或資料庫，保存明確且靜態的資訊，例如「使用者叫 Mike」「偏好用 Python」。

而另一個核心問題是「什麼時候更新記憶」。有些系統會選擇在互動中立即更新（熱路徑），例如在回覆使用者前，就把新事實寫進記憶體；也有些則會以背景任務的方式定期同步與整理，避免即時影響效能。兩者各有取捨：即時更新能保持高度個人化，但可能增加延遲；背景更新則更有效率，但需要設計良好的觸發條件與一致性策略。

最後，長期記憶的價值還在於提供一個統一介面，能輕鬆掛接不同的儲存後端（像是 Redis、Postgres、向量資料庫等），並附帶命名空間、TTL（存活時間）或清理策略，確保資料不會無限制膨脹，也能兼顧隱私與合規。

例子：Mem0 如何實現長期記憶

長期記憶的挑戰在於既要跨越多個 Session 保存資訊，又要確保檢索效率與語義相關性。

Mem0 提供了一個相對清晰的實作範式：

• 語意向量嵌入：透過 embedding 模型將對話或事件轉換成向量，並存入向量資料庫，用於之後的語意檢索。
• 跨 Session 上下文：為使用者維護持久化的偏好與知識，讓代理能在不同對話中延續理解。
• 高效檢索機制：結合向量檢索與圖結構檢索（如圖所示），既能模糊比對語意，又能明確查詢實體關係，確保取回的記憶既相關又精準。

這樣的設計讓代理不只是「看見當下的訊息」，還能在對話之間保有連續的自我，逐步累積對使用者的認識與任務經驗。

持久性與狀態管理：從拋棄式到持續運作

使用者真正信任的，不是「每次都從頭再來」的巧合成功，而是無論發生什麼都能完成任務的確定性。手機切 App、網路忽明忽滅、伺服器重啟……若你的 Agent 提供良好的一致性，那正是從玩具級瞬間跨進產品級的分水嶺。

核心情境

• 使用者場景：對話到一半被通知打斷、切走 App，回來希望無縫接續。
• 長任務場景：3 小時的資料分析在第 2:59 伺服器重啟，是否要從頭來過？

框架解法：檢查點（Checkpoints）＋時間旅行（Time Travel）

• 機制：不只儲存對話文字，而是把整個圖的 狀態（State) 序列化到儲存層（SQLite / Redis / Postgres）。狀態包含中間步驟的輸入輸出、變數與當前節點位置。
• 能力：
  • 斷點續傳：從確切節點恢復，不中斷地把故事說完。
  • 歷史重播：載入任一過去檢查點還原當時全貌，做到「時間旅行式除錯」。

確定性與一致性重播

在持久化工作流中，系統並不會「從程式碼停下來的那一行繼續」，而是會回到一個合適的起點，重播必要的步驟直到抵達中斷點。這樣做的好處是可以保證一致性，但也意味著任何「非確定性」或「具副作用」的操作都必須被妥善處理，否則在重播時會出現不同的結果，甚至重複執行危險的動作。

為了讓工作流在恢復時能保持一致，需要遵循幾個設計準則：

• 避免重複工作：如果一個節點中有多個副作用（例如日誌記錄、檔案寫入、網路呼叫），應拆分成獨立任務。如此在重播時，系統能依靠持久層中的結果，避免不必要的重複執行。
• 封裝非確定性操作：將隨機數生成、時間戳等非確定性邏輯包裝成獨立任務，並記錄其結果。這樣在重播時能保證輸出一致。
• 使用冪等操作：確保副作用（API 呼叫、資料寫入）具備冪等性，也就是「執行一次」和「執行多次」的效果一致。若任務啟動但未完成，系統會依賴持久層記錄的結果來恢復，避免資料錯亂或重複寫入。

這些原則讓持久化不只是「把狀態存起來」，而是能真正做到斷點續傳 + 一致重播。即使 Agent 被迫中斷，再次恢復時仍能沿著相同的歷程，產生相同的輸出。

Workflow 設計：從單行道到神經網路

真實世界不是直線馬拉松，而是十字路口與環狀交流道的混成體：條件分支、錯誤旁路、並行處理、人工審批與等待外部事件……若仍用一條線性的 ReAct 迴圈硬扛，系統會越補越碎。你需要的是把「思考與行動」升級為可視、可維護的決策網路。

框架價值

• 圖（Graph）建模：用狀態圖描述流程與拓撲，清楚表達「若工具 A 失敗→改走工具 B」「若情緒負面→轉人工客服」等邏輯，還能視覺化地調整節點與邊。
• 條件／分支／循環：把 if/else、重試、退避、補償動作（compensation）變成一等公民，而非散落在 Prompt 裡的隱性規則。
• 並行與節流：可控地開多路嘗試（如多模型/多工具競賽），同時用配額與速率限制守住穩定性與成本。
• 錯誤隔離與冪等：把外部副作用包裝為可重放的任務，重跑不重做；壞掉的是節點，不是整張圖。
• Human-in-the-Loop（HITL）：在關鍵節點內建暫停與續跑（如 interrupt/Command），例如刪庫前必須人審、發信前必須確認樣稿，降低風險、增加可追溯性。

Workflow 不同理解： Workflows 與 Agent

這圖是 LangChain 團隊對「工作流（Workflows）」和「代理（Agents）」的區分。他們認為 LLM 在系統中的角色有不同層次：

• 在 工作流模式 中，LLM 僅被嵌入到預先設計好的程式碼路徑裡，例如 Prompt chaining、平行化處理、Orchestrator–Worker、Evaluator–Optimizer 或 Routing。流程是人類先定義好的，模型只是在其中執行特定步驟。
• 在 代理模式 中，LLM 則能根據環境的回饋自行決定下一步要做什麼，例如呼叫工具、產生行動，再依據結果調整策略。

簡單來說，Workflow 比較像「照劇本走」，而 Agent 更像「自己導戲」，這也是 LangChain 為什麼同時提供工作流設計與 Agent 框架，讓開發者依場景選擇合適的模式。

總結

透過前面的探討，我們已經看見了從簡單的 ReAct 迴圈到完整 Agent framework 的差距，也理解了記憶、持久性與工作流等核心支柱，如何一步步支撐起產品級的 LLM 應用。這些概念讓我們對 Agent 的運作方式有了更深一層的認識，不再只是「跑得動的程式碼」，而是「能承受真實世界挑戰的系統」。

然而，這其實只是起點。真實的應用場景中還會遇到更多挑戰：安全與隱私、成本控制、可觀測性、評估與迭代方法論……每一個都足以決定一個 Agent 能不能走出實驗室、走進真實商業環境。

就讓我們繼續再接下來的日子中繼續往下深挖，探討 LLM Agent 應用的奧秘吧！

References：

• https://www.gocodeo.com/post/evaluating-memory-and-state-handling-in-leading-ai-agent-frameworks
• https://dev.to/foxgem/ai-agent-memory-a-comparative-analysis-of-langgraph-crewai-and-autogen-31dp
• https://www.zhihu.com/question/665012664/answer/1897954744963675108
• https://ithelp.ithome.com.tw/articles/10354011
• https://langchain-ai.github.io/langgraph/concepts/multi_agent/
• https://github.com/mem0ai/mem0
• https://langchain-ai.github.io/langgraph/concepts/pregel/